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(54) IEEE 1394 Set Top Box device driver 

(57) A device Interface for use in a receiver/decoder 
for a broadcast digital television system In which 
received signals are passed through a receiver to the 
receiver/decoder and thence to a television set. The 
receiver/decoder decodes a compressed MPEG-type 
signal, and is controlled by a remote controller handset, 
through an interface in the receiver/decoder. The opera- 
tion of the receiver/decoder is controlled by a virtual 
machine (VM) which includes a run time engine (RTE). 
The receiver/decoder includes a plurality of interfaces to 
external units. The device interface enables an applica- 
tion run by the RTE to access an IEEE 1394 interface. 
The device driver may be applied to other interfaces. 
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Description 

The present invention relates to interfacing of appli- 
cation programs to physical devices (peripherals)* par- 
ticularly but not exclusively in the context of 
receiver/decoders for digital television systems. 

The advent of digital transmission systems 
interxied primarily for broadcasting television signals, in 
particular but not exclusively satellite television sys- 
tems, has opened up the possibility of using such sys- 
tems for other purposes. One of these is to provide 
interactivity with the end user. 

The present invention finds specific application in a 
broadcast digital television system in which received 
signals are passed through a receiver to a 
receiver/decoder and thence to a television set The 
receiver/decoder decodes a compressed MPEG-type 
signal into a television signal for the television set. It is 
controlled by a remote controller handset through an 
interface in the receiver/decoder, also known as a set- 
top-box or STB. 

One way of providing the interactivity described 
above is to run an application on the receiver/decoder 
through which the television signal is received. It is 
desirable to enable a variety of applications to commu- 
nicate with a variety of physical devices in a transparent 
manner. Our co-pending applications PCT/EP97A)21 15 
and PCT/EP97/02116 descrtoe systems in which one or 
more applications can be downloaded by a 
receiver/decoder and communicate with physical 
devices in the receiver/decoder such as parallel and 
serial interfaces and smartcard readers by means of a 
device driver for each device and an overall device man- 
ager 

Puiisuant to the present invention, it has been pro- 
posed to provide the capability for a receiverAJecoder to 
communicate with other audio-visual equipment, for 
example, a digital video recorder over a high-speed dig- 
ital interface. The recently developed IEEE 1394 stand- 
ard provides a promising and flexible interface protocol, 
providing serial comnnunication rates of lOOMbit/s or 
more. 

A problem with using the IEEE 1 394 interface is that 
the interface bus may be reset or the parameters altered 
by a device connected to the bus other than the 
receiver/decoder, and this may cause problems for an 
application- This may lead to a requirement for greater 
memory and processing power to run more complex 
applications capable of dealing with the interface. This 
would add both to the cost of each receiver/decoder and 
also to the cost of developing and debugging applica- 
tions. 

Aspects of the invention attempt to alleviate the 
problems of interfacing applications to such interfaces. 
Although the invention offers most advantages in inter- 
facing a receiver/decoder to an IEEE 1 394 or the like 
Interface, it will be appreciated that the invention can be 
applied to interfacing other applications to interfaces 



whose parameters may change outside the control of 
the application. 

In a first aspect, the invention provides a method of 
communicating data, via a device driver, between an 
5 application and an interface having at least one feature 
to which an interface identifier is assigned, the or each 
interface identifier being !iat>le to change after at least 
one event, the method comprising: 

10 for at least one said feature, storing a correspond- 
ing logical identifier; 

providing the logical identifier to the application for 
directing communication associated with the cone- 
spending feature between the device driver and the 

15 application: 

maintaining correspondence between the or each 
logical identifier and the or eacfi feature independ- 
ently of the interface identifier assigned to the or 
each feature so that communication between the 

20 application and the device driver directed using a 
given logical identifier remains associated with the 
corresponding given feature following a change in 
the assignment of the corresponding interface iden- 
tifier to the feature. 

25 

In this way. although the association of interface 
identifiers and features may change from time to time, 
such changes can be made substantially transparent to 
tiie application, which can consequentiy be sinpler. 

30 Communicatton between the interfece and tiie 
device driver Is preferably directed ksased on the or each 
interface identifier; tiiis facilitates communication with 
the interface. 

Ijogical identifiers may be assigned only to features 

35 which are specified by one or more cipplications. This 
may reduce the number of logical identifiers required. 

Alternatively, the device driver may be arranged to 
compile a list of logical klentifiers and corresponding 
interface identifiers for aft said features, or for all fea- 

40 tures meeting pre-deter mined criteria, and preferably to 
update this list each time a feature is added or renrK^ved 
or altered, or if any interface identifier is changed. 

Although the method removes the need for the 
application to know the interface identifier, preferably 

45 the devtoe driver is arranged to comnrtuntcate the inter- 
face identifier assigned to a logical identifier to the appli- 
cation on request. This is found to feicilitate testing of a 
system remarkably, as it is possible for a high-level 
application to determine whether the interface and 

50 associated device driver is functioning as desired. 

Preferably, the device driver is arranged to accept 
requests from an application to define connections 
between physical devices connected to the bus using at 
least one logical identifier in place of an interface identi- 

55 f ier. This may facilitate manag&nent of connections by 
an application. 

The application is preferably arranged to communi- 
cate with the device driver via device manager means. 
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Provision of device manager means allows overall con- 
trol of communication to be effected, so that multiple 
applications may communicate with multiple devices 
without conflict. 

In a first preferred implementation, at least one said 
feature of the interface comprises a peripheral con- 
nected to the interface and the corresponding interface 
identifier conrprises the physical address (also some- 
times krrawn as a node address) assigned to that 
peripheral, the logical identifier comprising a logical 
address (which may also be termed a logical peripheral 
identifier) assigned to the peripheral. Thus, an applica- 
tion using a given logical address can continue to com- 
municate with a given peripheral (for example a digital 
video recorder), even if the physical address of the 
peripheral changes (for example following connection of 
another peripheral to the bus and subsequent bus 
reset). 

In such a case, maintaining correspondence prefer- 
ably includes interrogating each peripheral to which a 
logical address is assigned to determine the physical 
address assigned to the peripheral following the or each 
event for example a bus reset. This enables the assign- 
ments to be updated following any likely change in phys- 
ical address. 

Also in such a case, it is particularly advantageous 
if communicating the interface identifier for a given 
peripheral comprises communicating the physical (or 
node) address of the peripheral and also includes com- 
municating a further identifier of the peripheral, for 
example a unique node identifier containing further 
information identifying the peripheral. The unique node 
identifier may identify the manufacturer and/or vendor 
and/or model number of the peripheral, and may include 
a serial number. The unique node identifier is preferably 
at least 4 bytes, and more preferably 8 bytes long. 

According to a second preferred implementation, at 
least one said feature of the interface comprises a chan- 
nel of defined parameters available via the interface and 
the corresponding interface identifier comprises the 
interface channel number (or so-called channel identi- 
fier), the logical identifier comprising a logical channel 
identifier. In this way. it is not necessary for the applica- 
tion to keep track of interface channel numbers, which 
may change. The channels are preferably isochronous 
channels having a defined bandwidth. 

Preferably the device driver is arranged to receive a 
request from an application to allocate a channel of 
defined parameters (for example a channel having a 
defined maximum bandwklth) and to return a logical 
channel identifier if allocation is successful. Although 
the application need not know the interface channel 
nunriber. it is preferable if the device driver is arranged to 
' accept a preferred interface channel nunrtber and to allo- 
cate the preferred interface channel If available, and to 
allocate a free channel if the preferred interface channel 
is not available or if no preferred interface channel is 
specified. Provision of the ability to specify interface 



channels may facilitate control and testing of the inter- 
face by a suitable application, without requiring alt appli- 
cations to recognise interface channel numbers. 
Preferably the device driver is arranged to receive an 

5 identifier of a preferred interface channel, and to recog- 
nise a predetermined key in place of a valid interface 
channel nunrtoer as specifying no preferred interface 
channel but to report an error to the application if other 
invalid interface channel numbers are ^^edfied; this 

10 may assist in debugging applications. 

It is also preferable that the device driver is 
arranged to communicate tiie interface channel identi- 
fier to the application, and preferably also other param- 
eters, preferably including at least one of the maximum 

15 rate allocated to the channel, the rate currently availa- 
ble, the number of connections (if any) using the chan- 
nel, and the identifiers of each connection using the 
channel. This enables sophisticated management of 
communications by a suitable application, without 

20 requiring all applications to deal with such parameters 
to use the interface. 

fs^ost preferably, the first and second preferred 
implementations are both employed togettier. the 
device driver being arranged to accept requests from an 

25 appik»tion to define one or more connections between 
peripherals attached to the interface by reference to k>g- 
ical addresses and logical channel identifiers. Comk)ina- 
tion of the two implementations in this way provides the 
synergistic benefit that an application is able to estab- 

30 lish connections without needing to keep ti'ack of any 
details of the physical address of the peripherals con- 
cerned or the interface channel over which the ooiinec- 
tion is established. Preferably, the device drn^er is 
arranged to establish at least one of point-to-point oon- 

35 nections between specific peripherals and broadcast 
connections. 

During an event, such as a bus reset, in which inter- 
face parameters are liat^le to change, communication 
may be interrupted. Although the device driver may han- 

40 die certain events without requiring input from the appli- 
cation, it is preferable that the device driver is arranged 
to signal one or more events to an application pf the 
application so requests), the events preferably including 
at least one of reset of the bus (pref^ably separate 

45 events signalling beginning and end of reset), a change 
in txjs topology or channel or connection parameters. 

In a second aspect, the invention provides a device 
driver for effecting oommunk:ation between an applica- 
tion and an interface having at least one feature to 

so which an interface identifier is assigned, the or each 
interface identifier being liable to change after at least 
one event, the device driver comprising: 

means for storing at least one logical identifier cor- 
55 responding to a respective interface identifier; 

means for providing tiie togical identifier to the 
application for directing communication associated 
with the corresponding feature between the device 
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driver and the application; 

means for maintaining correspondence between 
the or each logical identifier and the or each feature 
Indepertdently of the inteiface identifier assigned to 
the or each feature so that conununication between s 
the application and the device driver directed using 
a given logical identifier can remain associated with 
the correspondir^ given feature following a change 
in the assignment of the corresponding interface 
identifier to the feature. i( 

The device driver be implemented in hardware, 
for example in a dedicated integrated circuit: this may 
provide enhanced speed of operation. More preferably, 
howev©-, the device driver is implemerrted at least partly is 
in software, preferably run by processing means which 
runs the application: this allows greater flexibility, 
requires less conponents. and allows the device driver 
to be updated more readily 

In a third aspect, the invention provides a data 20 
processing system comprising run-time engine means 
for running an application: 

interface means for connection to at least one 
device, the interface having at least one feature to 2S 
which an interfiace identifier is assigned, the or each 
internee identifier being liable to change after at 
least one event: 

device driver means conrprising: 
means for storing at least one logical identifier cor- 30 
responding to a respective interface identifier: 
means for providing the logical identifier to the 
application for directing communication associated 
with the corresponding feature between the device 
driver and the application: 3S 
means for maintaining correspondence between 
the or each logical identifier and the or each feature 
independently of the interfiace identifier assigned to 
the or each feature so that communication between 
the application and the device driver directed using 40 
a given logical identifier can remain associated with 
the corresponding given feature following a change 
in the assignment of the con^esponding interface 
identifier to the feature. 

45 

Preferred features of the first aspect may be applied 
to the second andi third aspects. 

The data processing system is preferably imple- 
mented in a receiver/decoder (for example a set-top- 
bax) which includes means for receiving broadcast data so 
(via satellite or cable), the interface preferably being 
arranged for connection to a digital video recorder or 
digital display device or computer for display or storage 
of at least a portion of the received data. The device 
driver means is preferably arranged to cooperate with ss 
device means for modifying the received data stream to 
produce a modified data stream for passing to said 
interface. 



TTie interface preferably conforms to the IEEE 1 394 
starxlard or a modification, refinement or variation 
thereof- Data may be transported according to the IEEE 
1883 standard. 

The application is preferatily run in an interpreted 
language and the device driver is preferably compiled. 

The invention is most preferably enployed in a 
receiver/decoder for enak^ling an application to commu- 
nicate with, for exanple, a digital video recorder over an 
IEEE 1394 kxjs. The device driver may be arranged to 
transmit commands for controlling the digital video 
recorder from the application and/or to receive data 
concerning the information stored on the digital video 
recorder: in this way an interactive application running 
in the receiver/decoder may control recording and play- 
back of programs or other data. The data to be commu- 
nicated is preferably MPEG format (by which is meant 
any variant or development of the basic MPEG format) 
data, but other formats may be used. 

Preferred features of the present invention will now 
be described, purely by way of exanple. with reference 
to the accompanying drawings, in which:- 

Figure 1 is a schematic diagram of interfaces of a 
receiver/decoder: 

Rgure 2 is a functional t^lock diagram of the 
receiver/decoder ; 

Rgure 3 shows certain components of the virtual 
machine and run time engine in more detail: 

Rgure 4 is a schematic diagram for explaining the 
flow of communication between an application and 
a remote peripheral via tiie device driver; 

Rgure 5 is a schematic diagram illustrating some 
components of the device driver. 

RECEIVER/DECODER BASICS 

Before describing a device driver emtxxiying the 
invention, the basic features of the preferred platform, a 
digital satellite receiver/decoder, will be explained 
briefly. 

Referring to Fig. 1 . a receiver/decoder 2020 or set- 
top-tx>x for use in a digital interactive television system 
in which the device driver of tiie embodiment is intended 
to be installed is schematically depicted. Details of a 
suitable digital interactive television system may be 
found in our co-pending applications PCT/EP97/02106 - 
021 17 to which reference should be made, and the dis- 
closures of which are herein incorporated by reference. 
For ease of reference, parts described in more detail in 
the aforementioned spedficatfons are generally desig- 
nated by the reference numerals used in those specifi- 
cations. The tjasic arrangement of the receiver/decoder 
will be summarised below, to assist in understanding 
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the function of the dev/ice driver. 

As described In more detail in the aforementioned 
specifications. referring to Figure 1. the 
receiver/decoder 2020 includes several interfaces: spe- 
cif icaliy, a tuner 4028 for the MPEG signal flow, a serial 
interface 4030. a parallel interface 4032. and two card 
readers 4036. one for a smartcard forming part of the 
system and one for bank cards or other smart cards 
(used for making payments, home t>anking, etc). The 
receiver/decoder also includes an interface 4034 to a 
modemmed back channel 4002 to the television signal 
producer, so that the user can indicate preferences, etc 
back to the television signal (programme) producer. The 
receiver also comprises a Run>Time-Engine 4008. a 
Devk;e Manager 4068 and a plurality of Devices 4062 
for running one or more applications 4056. 

For the purposes of this specification, an applica- 
tion is a piece of computer code for controlling high level 
functions of preferatrfy the receiver/decoder 2020. For 
example, when the end user positions the focus of a 
remote controller on a button object seen on the screen 
of the television set 2022 and presses a validation key. 
the instruction sequence assodated with the button Is 
run. 

An interactive application proposes menus and exe- 
cutes commands at the request of the end user and pro- 
vides data related to the purpose of the application. 
Applications may be either resident applications, that is. 
stored In the ROM (or FLASH or other non-volatile 
memory) of the receiver/decoder 2020, or broadcast 
and downloaded irrto the RAM or FLASH memory of the 
receiver/decoder 2020. 

Some examples of applications, described in more 
detail in the aforementioned ap>plications are:- 

An Initiating Application which is an adaptable col- 
lection of modules enabling the receiver/decoder 
2020 to be immediately operative in the MPEQ-2 
environment. 

A Startup Application which allows any application, 
either downloaded or resident, to run on the 
receiver/decoder 2020. 

A Program Guide which is an interactive application 
which gives full information about programming. 
A Pay Per View application which is an interactive 
service available on each PPV channel of the digital 
TV bouquet to ewiable the end user to buy the cur- 
rent event. 

A PC Download application enabling an en6 user to 
download computer software using the PC down- 
load application. 
• A Magazine Browser application comprising a 
cyclic video broadcast of images witii end user nav- 
igation via on-screen buttons. 
A Teleshopping applicatk)n enat)ling offers of goods 
for sale to be transmitted to tiie receiver/decoder 
2020 and displayed on the television 2022 and ena- 
bling the user to select a particular Item to buy 



Applications are stored in memory locations' in the 
receiver/decoder 2020 and represented as resource 
files. The resource files comprise graphic object, 
description unit files, variables t^lock unit f 3es. instruc- 
5 tion sequence files, application files and data files, as 
described in more detail in the above mentioned speci- 
fications. 

In the MPEG data stream, each module comprises 
a group of MPEG tattles. Each MPEG table may be fbr- 

10 matted as a number of sections. In the MPEG data 
stream, each section has a "size" of up to 4 kbytes. For 
data transfer via tfie serial and parallel port for exam- 
ple, modules similarly are split into tables and sections, 
the size of the section varying with the transport 

15 medium. 

Modules are transported in the MPEG data stream 
in the form of data packets of typically 188 bytes within 
respective types of data stream, for example, video data 
streams, audio data streams and teletext data streams. 

20 Each packet is preceded by a Packet Identifier (PID) of 
13 bits, one PID for every packet transported in the 
MPEG data stream. A progranune map table (PMT 
table) contains a list of the different data streams and 
defines the contents of each data stream according to 

25 the respective PID. A P ID may alert a device to the pres- 
ence of applications in the data stream, the PID being 
identified using the PMT table. 

The decoder contains memory divided into a RAM 
volume, a FLASH volume and a ROM volume, but this 

30 physical organization is distinct from the logical organi- 
zation. The memory may further be divided into mem- 
ory volumes associated with the various interfeces. 
From one point of view, the memory can be regarded as 
part of the hardware; from another point of view, the 

35 memory can be regarded as supporting or containing 
the whole of the system shown apart from the hardware. 

The system can be regarded as centred on a run 
time engine 4008 forming part of a virtual machine 
4007. This is coupled to applications on one side (the 

40 "high level" side), and, on the other side (the "loW level" 
side), via various intermediate logical units discussed 
below, to the receiver/decoder hardware 4061. The 
receiver/decoder heirdware can be regarded as includ- 
ing the various ports or interfaces as discussed above 

45 (the interface 2030 for the handset 2026^ tiie MPEG 
stream interface 4028, the serial interne 4030^ the 
parallel interface 4032. the interfaces to the card read- 
ers 4036. and the interface 4034 to the modemmed 
back channel 4002). 

50 With reference to Rgure 2. various applications 
4057 are coupled to the unit 4007, some of the more 
commonly used applications may t>e more or less per- 
manently resident in tiie system, as indicated at 4057. 
while others will be downloaded into the system, eg 

55 from the MPEG data stream or from other ports as 
required- 

The unit 4007 includes, in addition to the run time 
engine 4008, some reisident library functions 4006 
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which include a toolbox 4058. The library contains mis- 
cellaneous functions in C language used by the engine 
4008. These include data manipulation such as conv 
pression. expansion or oompsuison of data structures, 
line drawing, etc. The library 4006 also includes infor- 
mation about firmware 4060 in the receiver/decoder 
2020. such as hardware and software version numk>ers 
arxi availatjie RAM space, and a function used when 
downloading a new device 4062. Functions can be 
downloaded into the Ibrary. being stored in Flash or 
RAM memory. 

The run time engine 4008 is coupled to a device 
manager 4068 which is coupled to a set of devices 4064 
which are coupled to device drivers 4060 which are in 
turn coupled to the ports or interfaces. In broad terms, a 
device driver can be regarded as defining a logical inter- 
face, so that two different device drivers may be coupled 
to a common physical port. A device will normally be 
coupled to more than one device driver; if a device is 
coupled to a single device driver, the device will nor- 
mally be designed to incorporate the full functionality 
required for communication, so that the need for a sep- 
arate device driver is obviated. Certain devices may 
communicate among themselves. 

As will be descrft>ed below, there are 3 forms of 
communication from the devices 4064 up to the run time 
engine: by means of variak^les. buffers, and events 
which are passed to a set of event queues. 

Each function of the receiver/decoder 2020 is rep- 
resented as a device 4062. Devices can be either local 
or remote. Local devices 4064 include smartcards, 
SCART connector signals, modems, serial and parallel 
interfaces, a MPEG video and audio player and an 
MPEG section and table extractor. Remote devices 
4066, executed in a remote location, differ from local 
devices in that a port and procedure must be defined by 
the system authority or designer, rather than by a device 
and device driver provided and designed by the 
receiver/decoder manufacturer. 

When a new device 4062 is created, it can be 
installed in existing receiver/decoders 2020 by down- 
loading the relevant application 4056 from the broad- 
cast centre. This downloading is performed in the 
receiver/decoder 2020 by an application 4056 which 
checks the hardware and software versions and, if cor- 
rect, loads the software module representing the new 
device 4062 and asks a procedure of the library 4006 to 
install the new device code within the firmware (in Flash 
memory). This can provide a flexible and secure instai- 
latk>n of new functions within the receiver/decoder 2020 
without affecting the rest of the software 

The device manager 4068 is a common software 
interface between the application 4056 and the specific 
functions of the receiver/decoder 2020. The device 
manager 4068 controls access to devices 4062. 
declares reoeipt of an unexpected event, and manages 
shared memory. 

The run time engine 4008 runs under the control of 



the microprocessor and a common application pro- 
gramming interface. They are installed in every 
receiver/decoder 2020 so that all receiver/decoders 
2020 are identical from the application point of view. 

5 TTie engine 4008 runs applications 4056 on tiie 

receiver/decoder 2020. It executes interactive applica- 
tions 4056 and recaves events from outside the 
receiver/decoder 2020, displays graphics and text, calls 
devices for services and uses functions of the IflDrary 

10 4006 connected to the engine 4008"fbr specific compu- 
tation. 

The run time engine 4008 is an executable code 
installed in each receiver/decoder 2020, and includes 
an interpreter for interpreting and running applications. 

15 The engine 4008 is adaptable to any operating system, 
including a single task operating system (such as MS- 
DOS). The engine 4008 is based on process sequencer 
units (which take various events such as a key press, to 
carry out various afctibns), and contains its own sched- 

20 uler to manage event queues from the different hard- 
ware interfaces. It also handles the display of graphics 
and text. A process sequencer unit comprises a set of 
action-groups. Each event causes the process 
sequencer unit to move from its current action-group to 

25 another action-group in dependence on the character of 
the event, and to execute the actions of the new action- 
group. 

The engine 4008 comprises a code ioader to load 
and download applications 4056 into the 

30 receiver/decoder memory 2028. Only tiie necessary 
code is toaded into the RAM or Rash memory, in order 
to ensure optimal use. The downloaded data is verified 
by an authentication mechanism to prevent any modifi- 
cation of an applk:ation 4056 or the execution of any 

35 unauttiorized application. The engine 4008 furflier com- 
prises a decompressor. As the application code (a form 
of intermediate code) is compressed for space saving 
and fast downloading from tiie MPEG-2 transport 
stream or via a built-in receiver/decoder mode, the code 

40 must be decompressed before loading it into the RAM. 
The engine 4008 also comprises an interpreter to inter- 
pret the application code to update various variable val- 
ues and determine status changes, and an error 
checker. 

45 Before using the services of any device 4062, a 
program (such as an application instruction sequence) 
has to be declared as a "dient", that is, a logical access- 
way to the device 4066 or the device manager 4068. 
The manager gives the client a client numt)er which is 

so referred to in all accesses to the devk:e. A device 4066 
can have several clients, the number of clients for each 
device 4066 being specified depending on the type of 
device 4066. A client is introduced to the device 4066 by 
a procedure ''Device_Open Channel". This procedure 

55 assigns a client number to the dient. A client can be 
taken out of the device manager 4068 dient list by a 
procedure "Device^Close Charmer. 

The access to devices 4062 provided by the device 
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manager 4068 can be either synchronous or asynchro- 
nous. For synchronous access, a procedure "Device: 
Cair is used. This is a means of accessing data which 
is immediately available or a functionality which does 
not invotve waiting for the desired response. For asyn- 
chronous access, a procedure "Device: I/O" is used. 
This is a means of accessing data which involves wait- 
ing for a response, for example scanning tuner frequen- 
cies to find a multiplex or getting t>ack a table from the 
MPEG stream. When the requested result is available, 
an event is put in the queue of the engine to signal its 
arrival. A further procedure "Device: Event" provides a 
means of managing unexpected events. 

As noted above, the main loop of the run time 
engine is coupled to a variety of process sequencer 
units, and when the main loop encounters an appropri- 
ate event, control is temporarily transferred to one of the 
process sequencer units. 

Referring to Fig. 3. the device manager includes a 
queue 100 into which events from the devices are 
passed for temporary storage. At suitable intervals, the 
virtual machine sends a signal to this queue to extract 
the first item from it. This event item is moved to a queue 
structure 101 in the virtual machine. Depending on the 
priority level of the event item, it is inserted into the 
appropriate one of the 5 queues 0 to 4. Event items are 
extracted from the queue structure 101 by a queue 
selector unit 102 under the control of the run time 
engine. 

When an event is selected from the queue structure 
101. it is passed to a process sequencer unit engine 
104. which consists of a process sequencer unit driver 
105 and a set of process sequencer units 106. Each 
process sequencer unit is a set of action-groups linked 
together, so that each step from one action-group to the 
next action-group is. in general, dependent on the cur- 
rent action-group and the nature of the event. Different 
process sequencer units have different sizes and com- 
plexities, including one in which the "next" action-group, 
ie the action-group to which the system steps on in 
response to an event, is dependent solely on the nature 
of the event but is independent of the current action- 
group. Also, as is shown at the right-hand side of the 
process sequencer units blocK there may be several 
copies of. a process sequencer unit, ie several identical 
process sequencer units, to deal eg with several sepa- 
rate data streams using identical protocols through a 
single port 

When an event is selected, it is passed to the 
appropriate process sequencer unit. This selects the 
appropriate outlet from the current action-group on the 
process sequencer unit. This results in the appropriate 
next action-group being selected and the actions In that 
action-group being performed, involving eg the sending 
of a message to tiie device manager or the execution of 
a instruction sequence. Action-groups in the process 
sequencer unit can also send event messages to other 
process sequencer units. 



If a instruction sequence is selected, the identifica- 
tion of the instruction sequence is sent to a instruction 
sequence selector 107. This obtains the desired 
instruction sequence from a instruction sequence mem- 

5 ory 1 08 and passes it to a instruction sequence inter- 
preter 109. which executes the instruction sequence. 

The system also includes a fOter 110, which is 
loaded witii event types eg from the process sequencer 
units 1 06. When an event item i^passed from the queue 

10 100 in the device manager to the queue structure 101 in 
the virtual machine, its type or cfiaracter is matched 
against the list in the filter 1 1 0. and if it is of a type which 
is not recognized, it is rejected. This ensures that if say 
the device manager or the keyt^oard generates events 

15 of a type which the virtual machine cannot deal with, 
tfiose events are not passed to the queue structure 101. 
(If events of this kind were passed to the queue struc- 
ture 101. either they would accumulate in that queue 
structure or they might cause malfunctioning of the 

20 process sequencer unit engine 104.) 

Thus, it can be seen that our basic 
receiver/decoder platform provides conskJerable flexibil- 
ity in enabling an application to comnujnicate with a 
variety of devices. 

25 

DEVICE DRIVER FQR IEEE 1394 BUS 

Referring to Rg. 4, it can t>e seen that the IEEE 
1394 bus driver operates according to the above 

30 described scheme to facilitate communication between 
an application arxi a peripheral such a digital video 
recorder connected to the I EEE 1 394 bus. 

For high speed communication of data, for example 
for storage of MPEG real-time data, conventional serial 

35 and parallel interfaces, which are relatively straightfor- 
ward to control by an application, may not be fast 
enough. The device driver described below incorpo- 
rates a number of novel features which enable an appli- 
cation to access the IEEE 1394 bus effictently, and m^ 

40 enable control of, for example, a digital video recorder 
connected to tiie bus by a relatively unsophisticated 
application. 

The device driver can be considered as comprising 
a number of functional units which are separately 

45 accesible by an application, hereinafter termed com- 
mands. Each command interfaces with an application 
via a device 4062 run under the control of the device 
manager 4068 by means of one of the three standard 
procedures mentioned above, which are common to 

so other devices. Information may be passed between an 
application and the device driver by means of parameter 
tables. For ease of reference, the three basic proce- 
dures are summarised briefly below:- 

55 1) Device: Call. This commarKl can be used by an 
application for performing synchronous commarKJs 
or data transfer. Execution of the application is sus- 
pended until control is returned when the operation 
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by the device driver has completed; this allows 
operations which must be performed in strict 
sequence to be controlled reliably. 

2) Device: I/O. This command allows asynchronous 
operation. That is. an application can send a 
request for a data tranter or a particular function to 
be performed by the device driver and execution of 
the application can continue while the data transfer 
or function is performed by the device driver. 

3) Device: Event. This event trapping function ena- 
bles events to be signalled by the device driver to 
an application. arxJ for particular action to t>e taken 
by the application in response to the event inde- 
pendently of the code the application is executing at 
the time the event is signalled: effectiveiy the appli- 
cation is interrupted. Events may be prioritised. 
Events may t>e used to signal events occurring on 
the interface, such as a bus reset. 

The commands provided in a device driver embod- 
ying the invention will now be described. Each com- 
mand may be accessed by an application by passing an 
identifier of the command as a parameter via either the 
Device: Call or Device: lO prot>lems. Not all of the com- 
mands described below need be provided, and the 
functions of the commands may be altered. Although 
the commands may be independently provided or 
altered, as will be appreciated, certain synergistic bene- 
fits accrue from the combined functionality provided by 
the commands described. 

The commands will be described in terms of the 
features and functions provided by each command, as 
seen k>y an application, together with optional and pref- 
erable features. With the information given and specifi- 
cations provided, actual implementation of these 
features should be straightforward for one skilled in the 
art and the precise details are left to the implementor. 
As an example, each command could be implemented 
in software, preferably written in the C programming lan- 
guage and preferably conpiled to run on the processor 
used to run the application; however the device driver 
may be run on a s^cirate processor, and some or all 
commands may be irrplemented by dedicated hard- 
ware. Using the Call or 10 commands, the device driver 
may sigr^l information or pass parameters back to an 
application by setting values in a parameter tattle stored 
in memory whose address is passed to the device 
driver. 

It will be appreciated that the functionality 
described below for the commands implies certain 
underiying functions to be implemented by the device 
driver, for example, to deal with logical peripheral identi- 
fiers and logical channel identifiers, the device driver 
incorporates means for maintaining respective tables of 
logical peripheral identifiers and logical channel identifi- 
ers enabling them to be correlated to tiieir oorresporxl- 



ing interface features (physical address or interface 
channel number respectively). In addition, in the event 
of an occurrence such as a bus reset, the device driver 
is arranged to ascertain the new physical addresses 
5 and channel numbers and to update the tables so that 
taransition is relatively seamless as seen t>y an applica- 
tion. 

In addition, of course, the device driver includes 
means for actually effecting communication with the 

10 interface and for perfoi'ming necessary housekeeping 
tasks such as memory allocation and de-allocation. 
Some of these functions are schematically illustrated in 
Rg. 5. The details of these will depend on the specific 
physical hardware used, but will be straigfitforward for 

IS one skilled in the art to implement t>ased on the guid- 
ance presented in this specification, and with reference 
to the appropriate portions of the IEEE 1394 standards 
documentation (the disclosure of which is herein incor- 
porated by reference), so will not be described here. 

20 

Command: Bus 1394 Set 

This command enables basic interface parameters 
to be set by an application, preferably the size of a data 

25 reception buffer that should be allocated and the 
number of communication retries to be used when 
sending asynchronous commands via the interface. 
These parameters could be pre-set and the command 
omitted, but provision of this command enatTles commu- 

30 nications to be optimised for different applications. 
Although such parameters could very well be set asyn- 
chronously, it is found preferable to access this com- 
mand via the Call method, so that subsequent 
application commands are only executed after the 

35 device parameters have been stabilised. The command 
preferably signals an error to the application if the 
device driver is in the process of receiving data from a 
peripheral. 

40 Command: Bus 1394 Info 

This oommarKl returns basic information concern- 
ing bus topology to an application. Because it is less 
time-critical, it is preferat^ly accessed asynchronously 

45 via the lO command. 

Preferably, tf^s and indeed all or at least some 
asynchronous commands are arranged to pass a maxi- 
mum time (for example in ms) required for response (or 
a code, for example zero signifying no maximum time); 

50 this may enatsle tihe devrce driver to prioritise requests. 
Preferably the oommarKl returns information con- 
cerning the maximum data rate managed by the bus, 
the data rate availat>le at the moment of the call (that is, 
taking into account connections already active on ttie 

55 bus), the number of peripherals physically connected to 
the bus and their corresponding logical identifiers (to be 
discussed further below), and which logical channels 
are available at the time of the call. 
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With the IEEE 1394 bus, each peripheral con- 
nected to the bus is assigned a physical address which 
may change from time to time. 

It will be appreciated that, although specific provi- 
sion of this command is optional, it is desirable that the 
device driver maintains a table of logical addresses 
(also termed logical peripheral identifiers} which are 
constant for each peripheral (for a given session for a 
given application: the logical addresses may change if 
the receiver/decoder is re-set), so that on each execu- 
tion, an application can use a single logical address to 
identify a corresponding peripheral unquely and unam- 
biguously. The channel numbers assigned to channels 
may also vary, so the device driver also maintains a 
table of logical channel numbers. The device driver may 
then resporKl to an information request simply by look- 
ing up data from the appropriate tattle. 

Preferat>ly. information concerning the availability of 
channels is passed in binary form, as a bitmap, prefera- 
bly 8 bytes of information in which each bit encodes the 
availability of one of 64 logical channels (for example a 
"0" signifying that the channel is already allocated and a 
"1" signifying that the channel is availat)le for use). 

Command: Bus 1394 Info Periph 

This command is arranged to receive a parameter 
indicating a logical peripheral identifier and to return a 
two-byte physical address (also known as a node ID) 
corresponding to the physical address assigned to the 
peripheral on the interface, and preferably also to return 
an 8 byte unique node identifier preferably uniquely 
identifying the peripheral globally, or at least identifying 
the vendor or model number of the peripheral. This pro- 
vides the capability for a suitably sophisticated applica- 
tion to determine, for example, special capabilities of the 
equipment based on information identifying specific 
peripherals. 

The command is preferably arranged to signal an 
error if the interface is not physically connected to a 
functional IEEE 1394 bus or if the logical peripheral 
identifier is invalid (for example greater than a predeter- 
mined n^mum, preferably 63). and also to signal a 
pending bus reset, an error if the specified, logical 
peripheral identifier is not known, or if the device fails to 
respond within a specified time. 

The command is preferably accessed asynchro- 
nously by means of the Device: I/O procedure, a signal 
indicating completion or failure being passed by means 
of a parameter block. 

Command: Bus 1394 Alloc Channel 

This command is arranged to recave a request to 
allocate a channel. preferat)ly specifying the desired 
communication rate and preferat)ly also the desired 
interiiace channel to be used. A pre-determined code 
(for example OFFh) may be used to signify that no par- 



ticular interface channel, in which case, or in the case of 
the desired interface channel being occupied, the 
device driver allocates an availat)le channel. 

The command returns an allocated logical channel 

5 identifier if successful, and preferably signals an error in 
the applicable cases described above for the 
Bus_1394_lnfo_Periph command, or if no channels are 
available or if tiie requested data rate is higher than the 
maximum rate available. 

10 In simplified implementations of the device driver, 
for example using a very limited number of channels, 
this command, and the related two commands 
described next, may be omitted, at the expense of some 
flexibility. 

IS The command is preferably accessed asynchro- 
nously, by means of the Device: I/O procedure, a signal 
indicating completion or failure being passed by means 
of a parameter tslock. 

20 Command: Bus 1394 Info Channel 

This command is arranged to return information 
concerning the characteristics of a specified logical 
channel to an application. The command preferat)ly 

25 returns the maximum rate allocated to the channel (in 
Kbit/s), the rate available via the channel at the moment 
of the call, the real channel identifier (that is, the one 
assigned by the interface rather then by the device 
driver), the number of connections using the channel 

30 and tiie logical identifiers of each connection using the 
channel. 

The command preferably signals an error if the 
specified channel number is not allocated, in the event 
of an invalid identifier, in the case of a perKfing bus 
35 reset, or if the interface is not physically connected. 

The command is preferably accessed asynchro- 
nously, by means of the Device: I/O procedure, a signal 
indicating conpletion or failure being passed by means 
of a parameter block. 

40 

Command: Bus 1394 Free Channel 

This command frees a channel for communication 
by breaking down connections for a logical channel 
45 specified as a parameter (but preferably not de-allocat- 
ing the connection identifiers). The command preferably 
operates asynchronously and signals that comniunica- 
tions are still pending in the selected channel by means 
of an event. 

so 

Command: Bus 1394 Open Connect 

This command is arranged to receive a request 
indicating a logical channel identifier and preferably also 
55 a connection type and to initiate a point-to-point connec- 
tion between two devices or a broadcast in or out con- 
nection depending on the connection type specified. 
Where point-to-point connection is specif ted, the logical 
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peripheral identifiers of the two peripherals must also be 
passed to the device driver. Although variants of this 
comnnand could operate using physical addresses and 
interface real channel numbers, operation on the basis 
of logical parameters offers the advantages of simplified 
application operation mentioned above. 

TTie command returns a logical connection identi- 
fier if successful. 

Simplified implementations may omit the capafcwlity 
for defined point-tOiX>int connections to be specified; in 
typical appTications. there may only be a single device 
such as a digital video recorder connected to the bus. 
so broadcast connections may suffice. 

In some implementations of the device driver, open- 
ing of a particular connection may also automatically 
trigger re-routing of other signal paths within the 
receiver/decoder. For example opening of a broadcast 
in connection may cause automatic disconnection of the 
front end from the demultiplexer input, so that the 
demultiplexer is availat>le to process incoming data 
received over the IEEE 1394 bus. 

This command preferably signals an error when the 
maximum number of connections is reached, or in the 
other applicable cases mentioned above in relation to 
other commands. 

The command is preferably accessed asynchro- 
nously, by means of the Device: I/O procedure, a signal 
indicating con^tetion or failure being passed by means 
of an event. 

Command: Bus 1394 Close Connect 

This command receives a logical connection identi- 
fier and stops communication on that connection, there- 
after freeing the connection identifier for re-use. 

If signals are automatically re-routed within the 
receiver/decoder on opening of connections, the device 
preferably restores the connections to their previous 
state on closing the connection, or on closing the last 
relevant connection. For example, the demultiplexer 
input may be reconnected to the front end on closure of 
the last bro^cast in connection. 

The command is preferably accessed asynchro- 
nously, by means of the Device: I/O procedure, a signal 
indicating completion or feilure being passed by means 
of an event.' 

Command: Bus 1394 List Connect 

This command returns a list of active connections, 
only those involving the decoder itself, available at the 
time of the call, preferably in the form of a list comprising 
the number of connections arxl for each connection a 
logical connection identifier and a flag indicating the 
type of connection (point-to-point, broadcast in. broad- 
cast out). 

This and/or the command described below may be 
omitted in sinple implementations of the device, if only 



simple connections are provided. However, provision of 
such commands enables an application to monitor not 
only connections which it has itself established, but also 
to monitor connections established by other applica- 

5 tions. if more than one application is able to use the 
device driver at any one time, and to monitor wheth^ 
any connections have been unexpectedly closed. 

The command is preferably accessed synchro- 
nously, by means of the Device: Call procedure, as con- 

10 nections are liable to change frequentiy and an 
application may othenvise attempt to control communi- 
cations based on out-of date information, or else require 
polling of the response from the device driver. 

IS Command: Bus 1394 Info Connect 

This command accepts a logical connection identi- 
fier and returns the logical channel number over which 
the connection is established. The commarKi preferably 
20 also returns an Indication of the type of connection, and, 
in the case of a point-to-point connection, returns the 
logical addresses of the peripherals involved. 

As with the Ljst_Connect command, this command 
is preferably accessed synchronously. 

25 

Command: Bus 1394 Reset 

This command initiates a bus reset procedure, or 
returns an error If a bus reset is already pending. The 
30 command can t>e used to enalDle an application to seize 
control of the IEEE 1394 txis immediately after a reset, 
and is preferably accessed synchronously. The device 
driver preferably signals completion of txjs reset by 
means of an event discussed further below. 

35 

Command: Bus 1394 Send FCP 

This command in particular may be omitted or 
implemented differently The following description is of 

40 an example of an arrangement for sending data asyn- 
chronously over the IEEE 1 394 bus. 

This command receives a parameter t)lock contain- 
ing a message to be sent asynchronously as a conv 
mand or response to a perq^heral on the IEEE 1394 

45 bus. The parameter biock preferatsly contains an indica- 
tion of the type of message, the size of buffer that 
should be allocated for a response, the logical periph- 
eral identifier of the destination peripheral, the length of 
tiie message and the message itself. 

so The command preferatsly indicates successful 
sending or reports an error if sending was unsuccessful 
within a pre-determined number of retries or in the 
applicable cases described above for the Infb.Periph 
command. 

55 Since large amounts of data may potentially be 
transferred, the command is preferably accessed asyn- 
chronously, to allow the application to continue execu- 
tion while the transistor continues. 
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Preferably, the command is arranged to broadcast a 
message to all peripherals if a pre-defined logical 
peripheral identifrer is specified, for example 63. 

In simplified implementations of the device driver, 
this commarxj may be restricted to transmission of mes- s 
sages of fixed length, for example 32 bytes, which is suf- 
ftci&m for transmission of a command to a digital video 
recorder. 

Preferably, the device driver is capable of receiving 
and transmitting multiple requests quasi-simultane- 
ously. and of reporting multiple responses. However, 
simplified implementations may only provide capability 
for single sequential requests. 

In addition to the commands, which allow an appli- 
cation to send commands to the device driver, the 
device driver is an^anged to signal events to an applica- 
tion, via the device manager's event handling functions. 
The device driver implements the following events:- 

Ev Bus 1394 Rev FCP 

This event signals reception of an FCP frame from 
a peripheral, and provides a parameter block containing 
the source peripheral logical address, the type, length 
and content of the message. 

Ev Bus 1394 Channel 

This event signals channel allocation and dealloca- 
tion, and passes a list signalling which channels are 
allocated, preferably encoded in binary form as 
described above in relation to tiie Info command. 

Ev Bus 1394 Confiq 

This event signals peripheral connection or discon- 
nection, and provides a list containing the number of 
peripherals connected and their logical addresses. 

It will be appreciated that changes on the interface 
relating to this and the previously described Channel 
event must be monitored by the device driver in order to 
keep the correspondence table between logical and 
interface identifiers updated, even if the device driver 
does not signal such events to an application. 

Ev Bus 1394 Connect 

This event is used to signal a connection break, and 
provides a logical identifier to the application of ttie con- 
nection broken, and preferably also a list containing fur- 
ther information concerning the broken connection in 
similar format to that described above for the 
lnfo_Connection command. 

Ev Bus 1394 Lo Events 

This event may signal one or more low-level irrter- 
face errors, for exanrple peripherals holding the bus for 



longer than permitted, data or CRC errors, unexpected 
transactions, wiknown channel numbers or transaction 
codes and the like. This event is primarily useful for de- 
bugging and may be omitted in simplified implementa- 
tions of the device driver. 

Ev Bus 1394 Hi Events 

This event may signal one.or more high-le>/el bus 
conditions, including at least one (and preferatrfy both) 
of a txis reset start and finish, and also events such a 
cable power failure, detection of a loop in the bus. or a 
fatal error from which the device driver cannot recover 
by itself after multiple retries. 

Pus 1394 Off 

As a further event, this event may be used to signal 
errors internal to the device driver, such as not having a 
buffer available in which to store a received message. 

The atx3ve commands and events are merely illus- 
trative, and tiie invention may be implemented in a vari- 
ety of ways, and. in particular, some commands may be 
combined with others which perform similar functions, 
or some may be omitted in simplified implementations. 
Hardware and software implementations of each of the 
functions may be freely mixed, both between com- 
mands and within a single command; hardware imple- 
mentations may operate faster and free up processing 
power, whereas software implementations may be more 
readily updated. It will be readily understood that tiie 
functions performed by the hardware, the computer 
software, and such like are performed on or using elec- 
trical and like signals. Software implementations maybe 
stored in ROM or FLASH, or may be patched in FLASH. 

It will be understood that the present invention has 
been described above purely by way of example, and 
modifications of detail can be made within the scope of 
the invention. 

Each feature disclosed in the description, and 
(where appropriate) the claims and drawings may be 
provided independentiy or in any appropriate combina- 
tion. 

Claims 

1. A method of communicating data, via a device 
driver, between an applrcation and an interface hav- 
ing at least one feature to which a corresponding 
interlace identifier is assigned, the assignment of 
the interface identifier to the feature being suscepti- 
ble to change after at least one event, the method 
comprising: 

for at least one said feature, storing a cbnes- 
sponding k^gical identifier; 
providing the logical kientifier to tiie application 
for directing communication associated with 
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the corresponding feature between the device 

. driver and the application; 
maintaining con'espondence between the or 
eadh logical identifier and the or each feature 
independently of the interface identifier 
assigned to the or each feature so that commu- 
nication Ijetween the application and the 
device driver directed using a given logical 
iderrtifier remains associated with the corre- 

' spending given feature following a change in 
the assignment of the corresponding interface 
identifier to the feature. 

2. A method according to Claim 1 . wherein communi- 
cation betvyeen the interface and the device driver 
is directed based on the or each interface identifier. 

3. A method according to any preceding claim, includ- 
ing compiling a list of logical identifiers and core- 
sponding interface identifiers for all features 
meeting pre-determined criteria. 

4. A method according to any preceding daim. 
wherein the de^^ce driver is arranged to communi- 
cate the interface identifier assigned to a logical 
identifier to the application on request. 

5. A method according to any preceding daim. 
wherein the device driver is arranged to accept 
requests from an application to define connections 
between physical devices connected to the bus 
using at least one logical identifier in place of an 
interface identifier. 

6. A method according to any preceding daim 
wherein the application is arranged to communicate 
with the device driver via device manager means. 

7- A method according to any preceding claim 
wherein at least one said feature of the interface 
comprises a peripheral connected to the interface 
. and the corresponding interface identifier conv 
prises tlie physical address assigned to that periph- 
eral, the logical identifier comprising a logical 
address assigned to the peripheral. 

8. A method according to Claim 8, wherein maintain- 
ing correspondence indudes interrogating each 
peripheral to which a logical address is assigned to 
determine the physical address assigned to the 
peripheral following a bus reset. 

9, A method according to Claim 4 and Claim 7 or 
Claim 8. wherein communicating the interface iden- 
tifier for a given peripheral comprises communicat- 
ing the physical address of the peripheral and also 
includes communicating a unique node identifier 
containing furtiier information identifying the 



peripheral. 

10. A method according to any preceding claim, 
wherein at least one said feature of the interface 

5 comprises a channel of defined parameters availa- 

ble via the interface and the corresponding inter- 
face identifier comprises the interface channel 
number, the logical identifier comprising a logical 
channel identifier. 

10 

11. A method according to Claim 10. wherein tiie 
device driver is arranged to receive a request from 
an application to allocate a channel of defined 
parameters and to return a logical channel identifier 

15 if allocation is successful. 

12. A method according to Claim 10 or 1 1 , wherein the 
device driver is arranged to accept a preferred inter- 
face channel rujmljef and to allocate the preferred 

20 interface channel if available, and to allocate a free 
channel if the preferred interface channel is not 
availat)le or if no preferred interface channel is 
specified. 

25 13. A method according to Claim 10. 11 or 12, wherein 
the device driver is arranged to receive an identifier 
of a preferred interface channel, to recognise a pre- 
determined key in place of a valid interface channel 
number as indicating that no preferred interface 

30 channel is specified, and to report an error to the 
application if other invalid interface channel num- 
bers are specified. 

14. A method according to Claim 10. 11. 12 or 13 
35 wtierein the device driver is arranged to communi- 
cate the interface channel nunH^er to the applica- 
tion, and at least one other parameter selected 
from: the maximum rate allocated to the channel; 
the rate currently available; the number of connec- 

40 tions (if any) using the channel; and the identifiers 
of each connection using the channel. 

15. A method according to any preceding daim 
wherein the device driver is arranged to accept 

4S requests from an application to define one or more 
connections between physical devices attached to 
the interface by reference to logical addresses and 
logical channel identifiers. 

50 16. A metiiod according to any preceding daim 
wfierein the device driver is arranged to establish at 
least a broadcast connection. 

17. A method according to any preceding daim 
55 wherein the device driver is arranged to signal one 
or more events to an application, the events prefer- 
ably induding reset of the bus (preferably beginning 
and end of reset) and a change in bus topology or 
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channel or connection parameters. 

18. A device driver for effecting communication 
between an application and an interface having at 
least one feature to which an interface identifier is 
assigned, the or each interface identifier being lia- 
ble to change after at least one event, the device 
driver comprising: 

means for storing at least one logical identifier 
corresponding to a respective interface identi- 
fier; 

means for providing the logical identifier to the 
application for directing communication associ- 
ated with tiie corresponding feature between 
the device driver and the application: 
means for maintaining correspondence 
between the or each logical identifier and the or 
each feature independentiy of the irrterface 
identifier assigned to the or each feature so 
tiiat communication between the application 
and the device driver directed using a given 
logical identifier can remain associated with tiie 
corresponding given feature following a change 
in the assignment of the corresponding inter- 
face identifier to the feature. 



interrogate each peripheral to which a logical 
address is assigned to determine the physical 
address assigned to the peripheral following a bus 
reset. 

5 

25. A device driver acording to Claim 21 and Claim 23 
or 24. wherein the means for communicating the 
interface identifier for a given peripheral comprises 
means for communicating the physical address of 

10 the peripheral and also includes means for commu- 
nicating a unique node identifier containing further 
information identifying the peripheral. 

26. A device driver acording to any of Claims 18 to 25. 
15 wherein at least one said feature of the interface 

comprises a channel of defined parameters availa- 
ble via the interface and the corresporxjing inter- 
face identifier comprises the interlace channel 
ruimber. the logical identifier comprising a logical 
20 channel identifier. 

27. A device driver acording to Claim 26 including 
channel allocating means arranged to receive a 
request from an application to allocate a channel of 

26 defined parameters and to return a logical channel 
identifier if allocation is successful. 



19. A device driver according to Claim 18. wherein the 
device driver is implemented in software, preferably 
executable by processing means which runs the or 3o 
each application. 

20. A device driver acording to any of Claims 18 to 19, 
wherein the device driver is arranged to compile a 

list of logical identifiers and corresponding interface 35 
identifiers for all features meeting pre<ietermined 
criteria. 

21. A device driver acording to any of Claims 18 to 20 
including means for communicating the interface 40 
identifier assigned to a logical identifier to the appli- 
cation on request. 

22. A device driver acording to any of Claims 18 to 21, 
including mearis for accepting a request from an 45 
application to define connections between physical 
devices connected to the txjs using at least one log- 
ical identifier in place of an interface identifier. 

23. A device driver acording to any of Claims 18 to 22. so 
wherein at least one said feature of the interface 
comprises a peripheral connected to the interface 
and the corresponding interface identifier com- 
prises the physical address assigned to that periph- 
eral, the logical identifier comprising a logical ss 
address assigned to the peripheral. 

24. A device driver acording to Claim 23. arranged to 



28. A device driver acording to Claim 27, wherein the 
channel allocating means is arranged to accept a 
preferred interface channel number and to allocate 
the preferred interface channel if available, and to 
allocate a free channel if the preferred interface 
channel is not available or if no preferred interface 
channel is specified. 

29. A d^ice driver acording to Qaim 27 or Claim 28, 
wherein the channel allocating meansis arranged to 
receive an identifier of a preferred interface chan- 
nel, to recognise a predetermined key in place of a 
valid interface channel number as indicating that ho 
preferred interface channel is specified, and to 
rep>ort an error to the application if other invalid 
interface channel numbers are specif ieid. 

3a A method according to Claim 26. 27. 28 or 29 
including means for communicating the interface 
channel number to the application, and at least one 
other parameter selected from: the maximum rate 
allocated to the channel; the rate currently availa- 
ble; the number of connections (if any) using the 
channel; and the identifiers of each connection 
using the channel. 

31. A device driver according to any of Claims 1 6 to 30 
including means arranged to accept requests from 
an application to define one or more connections 
between physical devices attached to the interface 
by reference to logical channel identifiers and, in 
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the case of a request to define a point to point con- 
nection, by reference to logical addresses of the 
peripherals. 

32. A device driver according to any of Claims 1 8 to 3 1 . s 
including means arranged to establish at least a 
broadcast connection on request by an application. 

33. A device driver according to any of Claims 18 to 31 . 
including means for signalling one or more events io 
to an application, the events preferably including 
reset of the bus (preferat)ly beginning arxJ end of 
reset) and a change in bus topology or channel or 
connection parameters. 

IS 

34. A data processing system comprising: 

run-time engine means for running an applica- 
tion; 

Interface means for connection to at least one 20 
- device, the interface having at least one feature 
to vyhich an interface identifier is assigned, the 
or each interface identifier 
being liable to change after at least one event; 
and 25 
device driver means according to any of Claims 
18 to 33. 

35. A data processing system according to Claim 34 
implemented in a receiver/decoder which includes 30 
means for receiving broadcast data, the interface 
being ananged for connection to a digital video 
recorder or digital disp^y device or computer for 
display or storage of at least a portion of the 
received data. 35 

36. A receiver/decoder according to Claim 35, wherein 
the device driver means is arranged to cooperate 
with further device driver means for modifying the 
received data stream to produce a modified data 40 
stream for passing to said interface. 

37. A receiver/decoder according to Claim 35 or 36. 
wherein the interface conforms to the IEEE 1394 
standard or a variant thereof. 4S 

38. A receiver/decoder according to Claim 35. 36 or 37. 
wherein the application is run in an interpreted lan- 
guage and the device driver is compiled. 

so 

39. A receiver/decoder according to Claim 35. 36. 37 or 
38, wherein the device driver is arranged to transmit 
corrmrands for controlling a digital video recorder 
from the application and/or to receive data concern- 
ing the information stored on the cfigital video ss 
recorder. 

40. A receiver/clecoder according to Qaim 39. wherein 



the data to be communicated includes data in 
MPEGfomiat. 

A device driver for use in a receiver/decoder having 
run-time-engine means for running an application 
and an IEEE 1394 interlace to which at least one 
peripheral can t>e connected, the or each periph- 
eral capable of having a respective physical 
address assigned thereto, the interface being capa- 
bie of providing at least one corrvnunication chan- 
nel. the or each channel having a respective real 
channel identifier assigned thereto, the real chan- 
nel identifier assigned to each channel and the 
address assigned to each peripheral being liafe>le to 
change after a bus reset, the device driver being 
arranged for facilitating communication between 
the application and the IEEE 1394 interface, the 
device driver comprising: 

means for storing at least one logical address 
corresponding to a respective peripheral and 
for storing at least one logical channel identifier 
corresponding to a respective real channel; 
means for providing the logical address to the 
application for directing communication 
between the device driver and the application; 
channel allocating means for receiving a 
request from an application to allocate a com- 
munication channel, and. if a suitable commu- 
nication channel is available, for allocating the 
availalDle suitable communication channel and 
providing a logical channel identifier to the 
application for directing communication 
between the device driver and the application; 
connection allocating means for receiving a 
request from an application to allocate a con- 
nection between peripherals attached to the 
interface using a channel identified by said log- 
ical channel identifier, and allocating a connec- 
tion if possible, wherein, in the case of a 
request for a point-to-point connection between 
peripherals, the periphersUs are identified using 
said logical addresses; 

peripheral identity means arranged to receive a 
request from an application to identify a periph- 
eral corresponding to a given logical address 
and, in response thereto, to communicate the 
physical address of the corresponding periph- 
eral and to commuracate a unique node identi- 
fier containing further information identifying 
the peripheral; 

event signalling means for signalling to the 
application one of a plurality of events including 
an interface bus reset; 

channel identity means arranged to receive a 
request from an application to identify a chan- 
nel corresponding to a given logical channel 
identifier arKl. in response thereto, to communi- 
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cate the interface channel identifer of the corre- 
sponding channel and to communicate at least 
one further parameter of the channel indicating 
at least one of maximum allocated channel 
bandwidth and currently available channel 5 
bandwidth; 

wherein the channel allocating means is 
an^anged to receive an identifier of a prefenred 
real channel and to allocate the preferred real 
channel if available, and to allocate a free w 
channel if the preferred real channel is not 
available or if the preferred real channel identi- 
fier comprises a pre-determined key in place of 
a valid real channel identifier and to r^xjrt an 
error to the application if the preferred channel 75 
identifier corresponds to an invalid real channel 
identifier other than the pre-determined key. 

42. A receiver/decoder comprising means for receiving 
broadcast data; run-time-engine means for running 20 
at least one application; IEEE 1394 interlace 
means for connection to at least one peripheral 
device; and device driver means according to Claim 
41 for interfacing the or each application to the 
IEEE 1394 interface means, arxJ means for trans- 2s 
porting received data to the IEEE 1394 interface. 
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